Packet-based data networks continue to grow in importance as the communication mechanism of choice for new applications and services. Examples of this importance include web-based electronic commerce, electronic mail, instant messaging, voice over internet protocol (VoIP), streaming video (e.g., content from current websites such as youtube.com and hulu.com), internet protocol television (IPTV) and precision time protocol (PTP). In order to ensure successful delivery of these new applications and services, it is desirable to monitor both underlying network behavior and overall application performance on an ongoing basis. To meet these new monitoring needs, many new and innovative network monitoring and diagnostic tools have been developed and sold, either as an application that runs on an ordinary computer, or as an integrated hardware appliance.
One problem associated with the use of these network monitoring and diagnostic tools in network environments is the complexity of obtaining data from network sources and providing this data to the tools within the network monitoring system. Network monitoring applications and/or appliances require access to network data to perform their functions. Currently, this data access is typically provided using a network hub, using a network test access port (TAP) or using a switched port analyzer available on network switches. For example, with respect to this latter data source, network switches produced by Cisco Systems include a SPAN port to which traffic on the switch is mirrored. It is also noted that other data access methods may also be used or may become available in future networks.
A network hub essentially operates as a multi-port repeater for Ethernet networks. It is placed in-line with one of the existing links in a network and provides a copy of the data sent through that link to a third port, to which monitoring tools can be connected. The hub forces the monitored network segment to operate in half-duplex mode, which makes the use of network hubs impractical for most situations.
A TAP is placed in series with a network link and provides an exact copy of packets going in each direction on that link. TAPs are similar to network hubs, except that they do not require the network to operate in half-duplex mode. Furthermore, TAPs are generally designed to be failsafe so that they do not interfere with the network being monitored. To accomplish this, TAPs are typically designed so that the network can continue normal operation even if power is lost to the TAP, and so that the monitoring device is prevented from injecting packets back into the network. TAPS can be built-in (i.e., internal) to a network monitoring device, or can be external (i.e., stand alone) devices. Further, TAPs can be either passive or active. Passive TAPs meet the failsafe requirement implicitly while active TAPs often incorporate specific components (such as relays) which restore normal network operations when power is lost to the active TAP.
A SPAN port (also often called a mirror port) provides a copy of the packets within a network switch or router. The main limitation of SPAN ports is that typical switches support only a few SPAN ports per switch or router.
In addition to the foregoing technical limitations for providing access to network data, an additional consideration is the cost associated with hub, TAP and SPAN port enabled devices that can used to provide the data. This significant cost along with the growing need for network access and technical limitations of the common access techniques have led to a shortage of access to network data for monitoring purposes. Because of this limited access, most networks do not have sufficient monitoring points to meet the individual needs of all the network monitoring applications or appliances.
To help alleviate the problem of limited access to networks for monitoring, tool aggregation devices have been developed that allow sharing access to the monitored data. These tool aggregation devices allow users to take data from one or more network monitoring points, such as described above, and forward it to multiple different monitoring tools according to user specified forwarding rules. These tool aggregation devices typically use SPAN ports and TAPs as the predominant method of accessing network data. The tool aggregation devices further provide some filtering capabilities beyond traditional packet switches/routers including the ability to aggregate and filter traffic from multiple network sources and the ability to multicast traffic to multiple ports. Thus, tool aggregation devices enable users to share access to network data for monitoring and somewhat alleviate the problem of access to data. However, the filtering and forwarding capabilities of existing tool aggregation devices are built on single-forwarding-action techniques that are used for traditional packet switches and routers. As a result, existing tool aggregation devices have significant limitations for monitoring applications.
Traditional packet switches and routers are multi-port network devices that receive packets on one port, and forward them out of one or more other ports. The rules governing the behavior of such devices are contained in one or more tables. The forwarding tables may be either statically or dynamically configured, depending on the specific protocols used in the network. When a packet is received, the switch or router examines protocol information in the packet header (such as destination address) and uses that information to look up the one and only one appropriate action in the forwarding table. This characteristic of traditional packet switches and routers is referred to herein as a “single-forwarding-action” behavior or technique.
In short, when a traditional switch or router performs a lookup in a forwarding table, the lookup returns at most one result. This single-forwarding-action behavior is found in all network equipment today. Indeed, it is a fundamental assumption in the design of traditional network switches and routers that there can only be one “answer” that determines what to do with each packet, and thus it is only necessary to perform a “single-forwarding-action” on each packet. This rationale is so deeply engrained in network protocols today that packets cannot have more than one destination address. Even in multicasting packets or broadcasting packets, a single multicast destination address or a single broadcast action is used, respectively. This single-forwarding-action design has the advantage in networks that it prevents excessive copies of a packet from traveling through a network and unnecessarily consuming bandwidth. However, it has considerable disadvantages with respect to network monitoring systems where it is desirable to forward packets to multiple monitoring tools.
Similar to traditional packet switches/routers, existing tool aggregation devices also continue to be limited to the sequential nature of searching for a single matching rule within a memory such as a TCAM. Forwarding behavior is governed by matching packets against user-specified packet filtering criteria, but the first or highest priority user defined criteria that matches is the one that is acted upon. Subsequent lower priority user specified packet filtering criteria that would have matched the packet do not get acted upon. Users of existing tool aggregation devices that wish to forward packets according to multiple parallel overlapping criteria must know how to determine manually when such situations occur and must take appropriate action to work around this single-forwarding-action limitation. In practice, this means that users must manually provision additional higher priority filtering criteria to handle cases where filter overlaps exist (e.g., different forwarding actions are desired for the same packet based upon different filtering criteria).
Existing tool aggregation devices, therefore, require users to manually define filtering criteria, including prioritizing the order that the filtering criteria are implemented within a TCAM filter stage. When overlaps exist, only the first TCAM entry that matches gets acted upon based on TCAM priority. As such, downstream instruments may not see all the traffic that they are supposed to see when overlaps exist unless users manually account for the overlaps themselves. In attempting to account for these overlaps, however, the burden is on the user to understand the filter overlaps and to create filtering criteria and related forwarding actions for each overlap to guarantee that packets are directed to all the desired instrument ports.
Manually generating the filter criteria, however, particularly to handle overlaps, can quickly become a very difficult task, if not practically impossible. To ensure all filtering criteria is acted upon when overlaps exist, for example, users must configure the overlap intersections and correctly prioritize these intersections relative to one another and to the original filtering criteria. Further, if the user creates these additional intersections to prevent overlap, the user may then need to manually sum the counts in the added forwarding actions to achieve meaningful filter statistics. This manual overlap handling is a difficult task because simple overlaps involving independent fields (e.g., destination address field and VLAN field) may not be obvious to users, and more complex filtering criteria may expand into an enormous number of overlaps. Overlaps, therefore, cannot be readily understood or easily configured/maintained as a manual process. Further, a manual process is a complex and time consuming task having a greater probability of including errors in setting up the filtering criteria and related forwarding actions. Further, manually maintaining the filtering criteria is extremely difficult whenever modifications are desired because a user must go back and determine how these modifications will affect the prior filtering criteria manually set up to forward packets. With existing tool aggregation devices, many users simply ignore overlaps and accept the fact that tools will not receive all desired packets.
In short, there exists a considerable need to improve the ability of users to share network sources among a number of different monitoring tools for purposes of network monitoring. And there exists a considerable need to improve the ability of users to create, view and manage filtering criteria and related forwarding actions for purposes of network monitoring.